Be sure to read the AutoShare Home Page (www.dnai.com/~meh/autoshare/ on the Internet). An overview of the AutoShare documents is available as well.
EIMS (Eudora Internet Mail Server), a freeware SMTP and POP3 mail server for the Macintosh, may be downloaded from http://www.eudora.com/freeware/.
When AutoShare starts up for the first time (when upgrading from versions prior to 1.1), it automatically updates to the new resource format of the AutoShare Preferences file in the AutoShare folder within the System 7 Preferences folder. It will then empty the data fork in the AutoShare Preferences file and delete the AutoShare Times and AutoShare Hosts files.
When upgrading from 1.2 to 1.3, be aware that remote passwords have been made list-specific. This means that the passwords are no longer stored in STR# 201,22 (now used for the contents of the X-List-Host RFC field), but rather in STR# 1000...,22. If you have created any passwords, you must move these at the time of upgrading from 1.2 to 1.3, using the Admin, AppleScript or a resource editor.
Version 1.3 also simplifies the various AppleScript Options parameters by naming all of them simply Options. The underlying codes have not changed, so all of your scripts will get updated automagically. 1.3 furthermore adds new properties to the Misc Options and List Options classes and introduces the Send Mail command.
When upgrading from 1.3 to 1.4, be aware that new file extensions (.text and .txt) have been assigned to digests and text archives.
Version 1.4 also updates the AppleScript dictionary in a number of ways. The Quote property in List Options has been changed from a boolean value to a number (indicating a percentage). New List Options properties are RFC Headers, List Stuff, Address Protection, Tip Of The Day, Approval Both and Hard Unsubscribe. All boolean types in List Options have changed to non-boolean types to accommodate the default/override values. New Misc Options properties are Line Format, Keep Up, Processing, Status Window Position, Hide Window (formerly a command!) and Misc Stuff.
Version 1.4 furthermore includes a number of significant speed and memory enhancements.
The terms default and override are used often in this section. The generic meaning of these two words is applied to the list-specific configuration of AutoShare to indicate, that if you don't go out of your way to configure a given setting for a list, the respective general setting will be used instead. Many lists frequently share the same settings, which conveniently may be configured on the general level (a list-specific setting defaults to a general setting), whereas truly list-specific settings may be configured on a list level (a list-specific setting overrides a general setting). As a rule, strings being blank and numeric values of -1 are most often the override values indicating default.
The AutoShare Preferences file resides in the AutoShare folder within the System 7 Preferences folder and is created automatically by AutoShare, when starting up.
AutoShare also initializes the list-specific settings in this file by creating standard default values, when starting up. The list-specific configuration is stored in STR# 1001 and upwards, one STR# per list. Index numbers for fields and description of values within these are:
Apple Events scripting using AppleScript is perhaps the most important addition to System 7. This was enhanced in System 7.5 by introducing the scriptable Finder. AutoShare is fully scriptable, allowing you a convenient way of remote configuration. If you haven't tried using AppleScript, please locate the part of your System software that includes the files such as the Script Editor.
The various commands and properties in AutoShare's Apple Event dictionary may be viewed by dragging the AutoShare icon onto the Script Editor icon.
Once you have completed the installation of the AE system software, you may want to look into features like Program Linking, which enables you to control scriptable software from another Mac on the same AppleTalk network, even if you have access to the network via AppleTalk Remote Access (ARA). Program Linking is configured this way.
On the topic of errors, it is important to distinguish between actual AppleScript errors (most often unlikely) and a given AutoShare request not being successful (likely to happen from to time). When issuing for instance the GetSubscriber command, no result will be returned, if an AppleScript error, e.g. when fetching a property, occurs. On the other hand, an empty result will be returned, if there are no AppleScript errors, but, say, the subscriber could not be found. Your AppleScript scripting should take these kinds of situations into consideration.
The two AppleScript commands, SetRes and GetRes, set and get STR# resources in the AutoShare Preferences file. The feature is aimed at users who prefer not to use ResEdit.
Another three AppleScript commands, Analysis (generate an Analysis file), Subscribe (subscribe a user) and Unsubscribe (unsubscribe a user), have been added, as they may come in handy for remote
configuration using Program Linking.
The Unsubscribe command supports the list being all, so all lists are processed.
The AppleScript command, SetList (list-specific settings), has been added, as it is a documented feature currently not found within the interface. When the List property is not used, the remaining properties are directed towards the general settings in STR# 1000.
The Review command supports the list being all, so all lists are processed.
The Admin comes as a Miniature application, which means that the FaceSpan Extension must reside in the System 7 Extensions folder for the Admin to work.
The AutoShare Admin may be used on any Mac on the same AppleTalk network that the Mac running AutoShare is located on. Please read the above notes on configuration of Program Linking. When using the Admin remotely, be sure to put a copy of the AutoShare application on the Mac (preferably in the same folder as the Admin) on which you are using the Admin, so that the AutoShare AppleScript dictionary can be read by the Admin. Or you may use the ResEdit file entitled AutoShare (located in the Admin folder), which contains the AutoShare AppleScript dictionary only.
Balloon help has been added to the List, Lists and Subscriber windows, so that you may read about the various fields of these windows in detail.
The development environment of AutoShare does not rely on a framework such as PowerPlant or MacApp. The PowerPC native version is compiled and linked directly from sources to application and does not use a PowerPC conversion tool such as MacApp2PPC.
When AutoShare 1.0 was released, it was the first 68K list server for the Mac, and with the release of version 1.1, AutoShare was also the first true PPC native list server for the Mac.
The AutoShare folder in the System Preferences folder may now figure as a folder alias. The alias to the actual folder located elsewhere is resolved when AutoShare starts up.
When processing incoming files in the Filed Mail folder, AutoShare no longer waits for 5 seconds before processing the file (see STR# 2000,8 in the application's resource fork). It has been changed to zero seconds, and AutoShare now relies completely on whether the data and resource forks of the file to be processed are closed.
The primary transaction information listed as single lines (formatted as a series of transaction information tokens using space delimiters) in the logs applies to the following transaction types (the tokens are listed after the colon):
The standard list types are Subscription (contributions require subscription), Open (contributions do not require subscription), Moderated (the listmaster views contributions before being posted), Announcement (only the listmaster may post contributions) and Private (subscriptions are not allowed).
It may be added that the list-specific configuration enables list-based defaults for the subscription Options. If you prefer subscribers to for instance receive copies of their own contributions without any separate update of the subscriber's options, this is the way to go.
Posting privilegies may be turned on or off for individual subscribers (subscription, open and private lists). The post and nopost tokens may be applied as any other SET option, but with one important restriction: the subscriber cannot successfully use the two new tokens as a valid option within a SET command. They are administrative tokens only (whose option code is '4') to be used by the administrator (scripting commands, remote administration by e-mail or direct editing of main list files).
AutoShare has historically used the envelope sender, not the RFC From field, to determine the address of a list subscriber, as the envelope sender is generally considered to be the real address, although not visible when viewing the mail message. More often than not, the two are identical though.
If you would like new subscriber addresses to be extracted from the RFC From field, you may use the RFC From property in the AppleScript Options (Misc) to enable this. This means that the list files will contain the RFC From addresses for new subscribers, which will be used whenever a list server request or a list contribution takes a place. The envelope recipient of a list server request to be returned will furthermore be updated to the address in the RFC To field.
Using address protection prevents the action of harvesting e-mail addresses for unintended purposes.
When a subscribe command takes place, the list-specific index file in the Protected Addresses folder inside the AutoShare folder of the System 7 savvy Preferences folder is updated (entry is added). Same for an unsubscribe command (entry is removed). When a review command is issued, the e-mail addresses are replaced by corresponding address tokens.
When a subscriber posts, nothing is initially different. But when the list server receives the list contribution, the RFC From field body is replaced with a special address token, and all RFC X-Sender fields are removed. It is important that the body of your list contribution does not display your e-mail address.
When the subscriber would like to e-mail another subscriber off the list, the mail, with '<list>space<address token>' placed in the subject, is sent to the 'protected@<domain>' e-mail account, which redirects the mail to the recipient.
The envelope recipient gets updated, and the mail message is moved to the Incoming mail folder. If there is no match for the envelope recipient in the index file, the mail is returned to sender.
When sending an initial mail this way, it is encouraged that you be brief and merely state the purpose of your initiative, so that the communication may switch to the direct use of actual e-mail addresses on both sides. It is not intended that the server be allowed access to the contents of your mails more than necessary.
The address protection feature is enabled in AppleScript by the Address Protection property in List Options (STR# 1000..,26); the Admin, see the More List window.
We now move onto the issue of what is entitled spam, a term generally used loosely for various abuse of e-mail. You may think of spam as junk mail of many flavors.
It is next to impossible for a computer to figure out if a given mail is abusive, as the contents isn't reviewed in a meaningful fashion. Several steps may be taken though: 1. applying address protection prevents the spammer from harvesting e-mail addresses, 2. spam mails are often lengthy, and limiting the number of lines for list contribution bodies often helps, 3. writing a Before Processing process extender, which parses the mail for various words and optionally deletes the message file before it gets processed, and 4. using mail-back confirmation requires an additional effort from the spammer, who often prefers to move onto another easier target.
The format per entry is alias address, so if the subscriber addresses are envelope sender based, the RFC From address becomes the alias, and if the subscriber addresses are RFC From based, the envelope sender address becomes the alias.
When an unsubscribe request (standard message files only) takes place and the address isn't found in the main list file, the address will then serve as an alias and be looked up in the index file, and if the corresponding address is present in the list file, this address will be unsubscribed.
To make this feature active, you may use the Subscriber Aliases property in the AppleScript Options (Misc).
All may be used for the Unsub, Query, Set, Index, Get, Review and Search commands to apply the command to all subscribed lists, e.g. query all.
The subscriber name has been made optional in both the list server Sub(scribe) command and the AppleScript Subscribe command.
Auto-replies and vacation notices also insert Precedence: bulk. Furthermore, incoming messages with Precedence: junk and Precedence: list also get suppressed.
Filters directed at complete or partial addresses, e.g. list servers or individuals, may be used on top of this so safeguard against messages without a Precedence: RFC field header. In the Filters folder, the files are named based on the list name just like in the Listserv folder.
It is strongly recommended that you update all current files in your Archives folder to reflect the new convention!
You may choose both text and HTML formatted archives (rather than just one or then other). Having chosen this option (in the AutoShare application or using AppleScript; the Admin, see the List window), both text and HTML formatted archive files are created if necessary and updated when a list contribution is processed. The Index command will list both .text and .html file names. The Get command will format according to the file extension. The Search command will search both .text and .html files.
When a rollover archive file is created, a note is added to the log file, so that the listmaster becomes aware of it. In the case of HTML formatting selected, the listmaster may then choose to issue a GET command to receive the fully formatted HTML file by mail, save it to a text file and store it in a folder on a web server, thereby offering a convenient access to the archives. This may be further enhanced by using the new search and indexing tool Apple e.g., a public beta is at www.cybertech.apple.com/Appleeg.html.
The entry point folder path is configured within the list-specific settings, in AppleScript using the Web Path property in the Options (List). You may apply the one that is used most often as a general setting, but given lists such as private lists may choose to override with another path using a setting specific to the list. By assigning an invalid path, no web folders or files are created.
If you prefer to use your own html file in the entry point folder, then simply give this file a name other than index.html and make references to this file. It is assumed that your file references the index.html files inside the list subfolders.
Whenever a contribution takes place and the standard archives are updated, so are the web archives plus both the entry point level index.html file and the list subfolder index.html file.
A few changes have been made: all archived files now use hyphens instead of spaces, and some cosmetic changes have been updated for the archive files. It is recommended that prior archives be updated to reflect the new changes.
Specific to individual lists only (the general setting is always the above complete tree), the entry point folder may be configured to be the list folder itself; the upper layer of the subtree (the top-level folder and the top-level index.html) is not created, and the list folder is moved up one level to match that of the entry point folder. In AppleScript, use the Web Archives property (Complete versus Minimal) in the Options (Misc) to configure this selection.
Both Mac-to-HTML and MIME-to-HTML character conversions are automatically applied to both the standard and the fully automated web archives.
SetList Options {List: "fun-l", Remote Password: "rosebud"} When applying remote administration by e-mail, let the first body line (if the subject mode for list server requests, then the subject field instead) follow this word pattern:
<password> <command> <e-mail> <list> <rest>for instance
rosebud subscribe a@b fun-l Mr. XCommands supported so far are subscribe (the 5th word is just the rest of the line), unsubscribe (the name is not needed), set (the option is the 5th word), review (use a dummy e-mail address as the 3rd word) and analysis (the password and the command are adequate). The password is case-sensitive, the remaining parameters are not. All of these commands returns an e-mail to the sender with a status; the original command line is included, but the password is replaced by a generic word for safety reasons.
The post command is different from the above commands in several ways. You may use it to post to a list regardless of your client software's configuration, as the e-mail address and user name are picked up from the e-mail and rest tokens respectively. The list token is used to update the recipient, so the contribution gets posted to the list; no e-mail is returned to the sender or the contributor. The body of the contribution message is what follows the initial passworded line (if the subject mode, then put the passworded line in the subject and the subject as the first body line).
The password command may be used to change the password. Enter the new password as the 3rd word. If no list is specified, the request is aimed at the overall password. Both the old and the new passwords are replaced by generic words in the returned message. An e-mail is returned to the sender with a status.
The application and system commands have been added to accomplish remote launching and quitting of applications as well as system restart and shutdown. For either command, you may enter Launch or Quit as the 4th word, and the application command requires the 4 character creator (signature) code of the application in question in the 5th word. The 3rd word is ignored. PS: if you put application creator codes in STR# 206 of your AutoShare Preferences file, AutoShare will launch any of these applications (if not already running) every ten minutes. Keep them up!
Multiple lines using the above format are supported (in the body mode only). AutoShare stops processing the body once there are no more lines beginning with a valid password. While a post line must be the last of one or several passworded lines, it need not be the first.
For safety reasons, I highly recommend the recipient be autoshare@....
The passwords for remote administration by e-mail have been made list-specific in version 1.3, so you need to update all of your passwords to make your configuration current, using the Admin or AppleScript (if you edit your Preferences using a resource editor, please pay close attention).
If AutoShare detects a valid list in 4th word, the list-specific password works as well as the overall password, which works whether or not a valid list has been specified.
It may be added that the somewhat more complex Script By Mail AppleScript sample package offers the alternative of issuing AppleScript commands via e-mail.
Upon arrival, AutoShare detects the Content-type: application/x-www-form-urlencoded RFC field in the message and subsequently turns the mirrored web-originated message files into standard message files (list server requests and remote administration by e-mail respectively). Complete URL decoding is applied to the data received from the web browser.
A subscriber form may use the command, list, name and option tokens as well as the subscribe, unsubscribe, set and review commands.
The remaining commands, new in version 1.4, are: list, index, get, which, release, query, search and help, and new tokens are file (for Get) and string (for Search). (*)
An administrator form may furthermore use the password and email tokens as well as the analysis command (the post, password, application and system commands are not supported in web forms).
When AutoShare comes across a hook, AutoShare sends an AppleEvent to the process extender is question, if available. A list of parameters, which the process extender may use, is included in the AppleEvent.
The parameters in the passed list of the AppleEvent are 1. the folder path of the message file, 2. the file name of the message file, 3. the envelope sender of the message file, 4. the envelope recipient of the message file, 5. the RFC From body field, 6. the RFC To body field, 7. the RFC Subject body field, 8. the RFC Date body field, 9. the list name and 10. the contribution alert type.
The contribution alerts are the messages inserted into the beginning of the body, when contributions are not immediately posted for various reasons: 1. not subscribed, 2. announcement list , 3. subscriber not allowed to post, 4. response is smaller than quote, 5. moderated list and 6. too many lines in contribution.
For suggested variable names for the above parameters and contribution alerts, see the Before Processing sample Template process extender.
Process extenders reside at the top level inside the 'Process Extenders' folder, which resides in the same folder as the AutoShare application. Aliases are supported for process extenders, so that these may physically reside elsewhere.
There are several sample process extenders inside each sample type folder. One from each folder may be made active by placing it at the top level inside the 'Process Extenders' folder. All sample files are script applications with the source preserved ("Save As..." Application with both "Stay Open" and "Never Show Startup Screen" enabled).
The following describes the various AutoShare process extenders and also makes references to the sample process extenders. The class and event IDs used are in parenthesises after the process extender name.
Before Processing ('AuBP', 'aUBP')
The Before Processing hook is placed at the very beginning of the processing of a message file in the Filed Mail folder. The execution of the Before Processing process extender is triggered by AutoShare becoming aware that a file resides in the Filed Mail folder.
Within the Before Processing sample folder, the Template process extender illustrates the basic starting-point. The main AppleScript handler merely picks up the call from AutoShare. The purpose of the idle handler is to reduce processing time being allocated to the application when the main handler is not being called.
The List Parameters process extender displays the various parameters being passed from AutoShare. Be sure to have AutoShare running in the background when testing this sample.
The Unconditional Filter process extender intercepts the main AutoShare processing by copying the message file to another folder and completes this task before AutoShare begins its actual processing of the file. If the process extender deletes or moves the file, AutoShare is left with no processing of its own to do.
The Write Log process extender writes a line to the AutoShare log. This sample is particularly interesting, as the sample application calls the very same AutoShare application, which triggered it. AutoShare waiting for the process extender to complete its task causes a Catch-22 situation, because AutoShare does not respond to high-level events during instances of its main processing phase to avoid various high-level event and open file conflicts. The trick is to let the process extender have its calls to AutoShare bypass its requests for high-level event replies; the actual task will be processed instantly though.
After Processing ('AuAP', 'aUAP')
The After Processing samples resemble those of Before Processing. The only difference is the time of being triggered and thereby the message file. This type of process extender is executed just before the final processed file is copied to the Incoming Mail folder.
Subscribe ('AuSU', 'aUSU')
The Subscribe Write Log sample writes a line to the AutoShare log. Be sure not to have your process extender delete, move or otherwise change the message file.
The FileMaker Pro sample creates a new record in a FileMaker Pro database file having a very simple data structure.
The Send Message sample sends a basic welcome message to the new subscriber.
Unsubscribe ('AuUS', 'aUUS')
The Unsubscribe Write Log sample writes a line to the AutoShare log. Be sure not to have your process extender delete, move or otherwise change the message file.
The FileMaker Pro sample looks up the subscriber in the database and sends a message of when the original subscription took place.
After Digest ('AuAD', 'aUAD')
The After Digest Write Log sample writes a list-specific line to the AutoShare log.
Contribution Alert ('AuCA', 'aUCA')
The Contribution Alert Multiple Alerts sample illustrates how to return a list of strings to AutoShare; note the AppleScript return command in particular. The row of lines will override the default text of the given alert message.
You distinguish among the various contribution alert types by using the code of the contribution alert type parameter. The sample shows this in full.
Test Bounce ('AuTB', 'aUTB')
The Test Bounce Write Log sample writes a line to the AutoShare log.
As the parameters reflect the Test Bounce file in the AutoShare Temp folder, you may choose to delete this file and instead send another message to the subscriber in question.
System ('AuSY', 'aUSY')
The System Write Log sample writes a line to the AutoShare log immediately before a System command using remote administration by e-mail takes effect. As the normal purpose of the contribution alert type parameter does not apply, the parameter is instead used to indicate whether the Mac is to be 1. restarted or 2. shut down.
To reinforce that the unquoted part of a response contribution must be at least a given percentage of the complete message body, change the proper list-specific setting to this percentage. If it does exceed more than the percentage, the message is returned to sender. John Norstad's NewsWatcher applies this restriction to news responses (50% only though), if the news server in question is configured to reject postings which contain more quoted text than new text.
The X-List RFC field headers and respective field bodies are:
X-List-Digest, X-List-Archive, X-List-Post and X-List-Host are new.
Other X- headers and respective fields are
When the MIME property in the AppleScript Options (Misc) is set to Text Plain (default), the following MIME RFC field is inserted after the Mime-Version field:
Content-Type: text/plainAnd when the property is set to MIME QP or QP Always, the following MIME RFC fields are inserted after the Mime-Version header field:
Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printableMac-to-MIME conversion is applied accordingly in the body of the outgoing message.
MIME QP: The MIME property makes a difference for the outgoing message files that are originated by AutoShare and not directly derived from message files arriving in the Filed Mail folder (such as logs, digests and admin notifications). For list contributions and auto-responses, Mac-to-MIME conversion will depend on the MIME RFC fields of the original message as well; the Mac-to-MIME conversion does not take place unless the 'Content-Transfer-Encoding: quoted-printable' field is located (besides the MIME property being set to Quoted-Printable).
QP Always: The MIME Quoted-Printable encoding takes place whether the message file is originated by AutoShare or not.
AutoShare offers MIME Quoted-Printable support for auto-responses with enclosures as well. (The name of the enclosure file will be added to STR# 8193,1 (2 and 3 are also used) of the outgoing message to insure that boundary lines are inserted correctly at the time of the Mac-to-MIME conversion.)
Both message and digest subscribers receive the monthly help files.
If several lists are to share one monthly help document, you may create aliases reflecting the normal file name format and pointing to the same document.
If a + (plus sign) is appended to the prefix, the prefix will appear at the end of the subject instead.
Headers and footers also appear at the beginning of and end of digests.
For a moderated list, the list contributions forwarded to the list master do not include headers or footers. They will be inserted when the list master posts the contribution to the list.
If several lists are to share one header or footer document, you may create aliases reflecting the normal file name format and pointing to the same document.
The change is that AutoShare now offers binary searches of the line-based subscription lists, so that a search for a given address is completed much faster than before. This is in part accomplished by verifying at start-up that the lists are sorted, and when not, sort them using a QuickSort algorithm.
The searching, sorting and insertions for lists are configured using the List Sort property in the Options (Misc); the new status will be saved to the disk settings immediately, but will not become active until the Run command has been issued or AutoShare is restarted. The property may be set to Domain, User or Unsorted; when configured as the latter, AutoShare will not check for lists being ordered when starting up and will apply a simple linear search when looking up subscribers; new subscribers will in this case be appended to the end of the list file.
When sorting, the AutoShare application heap memory is utilized as tightly as possible. Each subscriber takes up 4 bytes plus the number of characters in the address line in question. With an average subscriber string length of 36 characters, a list file of 1,000 subscribers requires around 40K at the time of sorting. It may be noted that if you stick with the same configuration from day one, no sorting will ever have to be applied as new subscribers are placed in their proper location from the very beginning, always leaving the list file sorted.
When subscriber records are added (sub), replaced (set) or deleted (unsub) for a ordered list, an efficient file processing technique optimizes the speed dramatically. Even huge list files will require little time to stay fully updated at all times.
Anyone may vote on a given topic by sending a mail to the Poll address. The topic of the vote is based on the specific subject line. The actual vote of the sender is based on the first line of the body. Whenever a sender tries to vote, the overall vote statistics are returned. If it's the sender's first try, the pool of votes gets updated, and following attempts results in informing the sender of the number of attempts so far.
The poll account may be used to gather all kinds of distribution data based on the key strings (max 20 characters each) in the body. The poll account rejects all subjects which have no corresponding document or uses the Default document. The poll action is triggered by the /=poll token, which should be placed in all docs, also the Default doc, in the poll folder. The poll status returned to the sender shows the overall distribution sorted by selection, and graph bars help illustrate the results.
A set of pre-defined key strings may be attached to a poll. When an invalid key string is encountered, AutoShare returns a note to the sender asking for another try. The series of case-insensitive key strings resides in the 'STR ' resource, beginning at 1001 and upwards, of the poll file in question (no user interface has yet been designed).
Two new folders are introduced, the Mail Back folder and the Hold Mail folder. The mail-back feature works on a per account basis, so if you would like mail-back enabled for a given account, you re-configure the EIMS Save as files account to point to not the Filed Mail folder, but the Mail Back folder instead. Once the message file appears in the Mail Back folder, AutoShare moves it to the Hold Mail folder and puts a new message file in the Incoming Mail folder, asking the user to confirm by replying to the mail; the first line in the body displays the confirmation key, which is the unique name of the original file generated by EIMS. When the confirmation message file arrives in the Mail Back folder, AutoShare checks the first line in the body, and if it matches the name of a file in the Hold Mail folder, this file is moved into the Filed Mail folder, and the confirmation file is deleted.
The contents of the returned mail-back message to the user will go beyond including just the confirmation key in the first line of the body, if you put a line-based text file entitled Mailback in the autoshare/docs folder. A blank line and the contents of this file will be added, thereby explaining the user what to do. The /=original and /=subject tokens are supported in the Mailback file.
Deletion of unconfirmed message files takes place automatically. The Hold Mail Check property in the Options (Misc) (STR# 201,12 in the Prefs) indicates in minutes (default is 10 minutes) how often AutoShare should check for expired files, and the Hold Mail Expire property (STR# 201,13) indicates in minutes (default is 600 minutes = 10 hours) the duration before expiration takes place from the time the file was created by EIMS.
The AutoShare account is a unique and more complex case, as you may want some commands enabled for mail-back and others disabled. To feature this, a new list-specific Mailback property is introduced in the AppleScript Options (List) and corresponds to STR# 1001...,20 in the Preferences file. If the string is blank, STR# 1000,20 is looked at for the general setting, and if the string there is blank too, no mail-back is enabled for the given list. You may add N (None) to the list-specific string to avoid use of the general setting.
The A (All) enables mail-back for all commands for a given list, and if a command does not contain a reference to a list, the general setting is used. Here are the letters for the various commands: S=sub, U=unsub, E=set, Q=query, R=review, I=index, G=get, H=search, W=which, L=list, C=release.
The list-specific string SUQL indicates that the sub, unsub and query commands are mail-back enabled, while others are not; the status of the list command is determined by the general setting, as it is not specific to any given list.
If all STR# 1000...,20 strings are blank (default), no mail-back takes place for the list server account. It therefore doesn't matter whether the EIMS account points to the Mail Back folder or the Filed Mail folder.
When using the automated bounce feature, it is strongly recommended that the bounce account not be identical to the EIMS postmaster account, as mail received by the bounce account is for AutoShare only. And as usual, it is a must that the domain of the bounce address reflect that of the mail server.
Whenever bounce mail arrives, AutoShare's bounce module will process the message file and subsequently send the admin a mail if a list subscriber could not be located. Otherwise the list subscriber is updated in the Bounces On Hold file located in the AutoShare folder inside the System 7 savvy Preferences folder. The subscriber address, the list name, a sent counter (initialized to zero), a received counter (initialized to zero) and an entry created time are the five pieces of information, which are added to each entry in the Bounces On Hold file.
Every so often (using the Bounce Send Mail property in the Options (Misc)), AutoShare sends a mail to each entry in the Bounces On Hold file, and the sent counter is incremented by one. If the subscriber address continues to bounce, the new bounce message causes the received counter of the entry to be incremented by one (additional bounces will not cause the value of the received counter to grow beyond the value of the sent counter, as it should not be a factor how busy the given list is), and once the received counter hits a given threshold (using the Bounce Received Threshold property in the Options (Misc)), the subscriber get unsubscribed, and the entry is removed from the Bounces On Hold file.
If the subscriber address does not continue to bounce, the sent counter continues to grow while the received counter does not, and once the difference of the two values is beyond a given threshold (using the Bounce Sent Threshold property in the Options (Misc)), the entry is considered stable and removed from the Bounces On Hold file.
Entries are also deleted when the current time exceeds the entry created time by a given threshold value (using the Bounce Delete Threshold property in the Options (Misc)). The purging takes place every time test bounces are sent.
The Bounces On Hold file includes entries based on soft bounces only. Hard bounces get unsubscribed immediately per the default behaviour (which includes sending a mail to the listmaster), but be configured to act as soft bounces. A hard bounce is defined as a sender situation which is not likely to change (such as the sender's address not known), while a soft bounce relates to a temporary situation (e.g. the mail server of the sender may be down due to a network problem). AutoShare does not support many bounce formats at this time, and the 550 code (user unknown) is the only one so far to trigger a hard bounce status.
Situations relating to AutoShare being low on memory are often temporary, so one reminder only per incident will be issued. Future transactions will be processed in a normal fashion, although some specific transactions may cause history to repeat itself, at which times further reminders will be issued.
When a disk is close to being full, the situation is not likely to change much by itself. Both periodical and pre-processing checks applied to all involved volumes will be performed based on a worst-case scenario, and when the threshold has been hit, the processing of the current task will be completed if possible, the reminders will be issued, and AutoShare enters the non-processing mode. Once the situation has been resolved, AutoShare resumes normal processing.
When AutoShare gets low on disk space, it no longer shut downs, but instead moves into the non-processing mode, allowing only events (including AppleEvents) and Keep Applications Up to be processed. Messages are mailed to the listmaster every hour to inform of the low disk space situation. When adequate disk space has been restored (checking for this every so many minutes (defaults to 60); STR# 201,27; AppleScript, see the Processing property in Misc Options; the Admin, see the More Misc window), AutoShare returns to normal processing. (*)